[recipes] Ship libLLVM and libclang-cpp dylibs alongside the static libs#81
Open
vgvassilev wants to merge 1 commit into
Open
[recipes] Ship libLLVM and libclang-cpp dylibs alongside the static libs#81vgvassilev wants to merge 1 commit into
vgvassilev wants to merge 1 commit into
Conversation
vgvassilev
force-pushed
the
llvm-recipes-build-dylib
branch
5 times, most recently
from
0e3cfb5 to
c27f9c2
Compare
…ibs. The recipes link clang as a fully-static binary, so the linker drops any TU that no in-tree caller references. clang::TypeName functions (QualTypeNames.o) are the canonical victim: nothing inside clang itself calls them, but plugins (clad, CppInterOp, ...) do, and the plugin's symbol lookup then fails at load time. apt's distribution clang doesn't have the problem because it ships the umbrella dylib. Add a small llvm_build.dylib_flags() helper that returns LLVM_BUILD_LLVM_DYLIB / LLVM_LINK_LLVM_DYLIB / CLANG_LINK_CLANG_DYLIB on Linux and macOS, and an empty list on Windows -- where LLVM_LINK_LLVM_DYLIB is force-OFF and setting CLANG_LINK_CLANG_DYLIB=ON then trips clang's consistency check. Call it from llvm-release, llvm-asan, and llvm-msan. Static archives stay in install/lib; the dylibs are shipped beside them, and clang is linked against the dylib so its full symbol surface is loaded at startup. This is the layout Debian and Fedora use. llvm-root and llvm-wasm intentionally untouched: cling expects to link statically against LLVM/Clang, and the wasm path is its own emscripten-driven shape -- both can opt in separately if needed.
vgvassilev
force-pushed
the
llvm-recipes-build-dylib
branch
from
c27f9c2 to
6d9a197
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The recipes link clang as a fully-static binary, so the linker drops any TU that no in-tree caller references. clang::TypeName functions (QualTypeNames.o) are the canonical victim: nothing inside clang itself calls them, but plugins (clad, CppInterOp, ...) do, and the plugin's symbol lookup then fails at load time. apt's distribution clang doesn't have the problem because it ships the umbrella dylib.
Add LLVM_BUILD_LLVM_DYLIB / LLVM_LINK_LLVM_DYLIB / CLANG_LINK_CLANG_DYLIB to llvm-release, llvm-asan, and llvm-msan. The static archives stay in install/lib; libLLVM-N.so and libclang-cpp-N.so are shipped beside them and clang is linked against the dylib so its full symbol surface is loaded at startup. This is the layout Debian and Fedora use.
llvm-root and llvm-wasm intentionally untouched: cling expects to link statically against LLVM/Clang, and the wasm path is its own emscripten-driven shape -- both can opt in separately if needed.